@bigorn0 Hi Ugo!

Couldn't agree with you more, that we need to strive for a well-organized codebase as much as it makes sense. However, I don't think that "helpers" folder is completely meaningless, because devs can quickly detect these folders as a place for commonly used functions. Definitely, there is a room for decoupling the mentioned cluster.js file down to more granular modules of responsibilities. But it also would require another deep round of refactoring of the logic itself. From what we've been discussing with the team, this version of a reorganized code in comparison with what we had previously in the studio repo - is way more readable and understandable even with such unideal decoupling. So in order to provide iterative deliverables - it looks "fine" for now.
I think the points that you've shared in a PM over slack are extremely valuable and worth to be captured in a generalized form on our Architectural Guidelines page. It also may include examples of how to "do / do not" do in particular specific cases. That could be a starting place where everyone in the team could align the expectations about how to organize their code in any plugin repo. What do you think?

Looking at the content of helpers folder it is quite obvious the core logic is about retrieving/discovering database objects and hierarchy that we try to model so definitly, helpers has nothing to do with it. I could name it <blah>, it would give the same information. This initial implementation is a good opportunity for a change even if it is burried from app or older logic. I'm fine with taking this as a first step as long as code restructuration and clarification of the api come right after as a follow up step.

About the fact that dev can quickly identify commonly used functions then again, i don't get it because most of the functions inside that helpers folder are specific to Couchbase. Most of the functions inside are following an interface and implement what's expected by the application (REWorker scenario) for a given database structure discovery workflow then it is best to organize and surface that fact. I think there are enough abstractions and technics in Javascript to achieve that goal even without Typescript.

https://app.gitbook.com/o/HBtg1gLTy0nw4NaX0MaV/s/k3cNzEeXGnIxGNnOQdDa/architecture/architectural-guidelines Already promotes the small, focused, well scoped module vs the GOD object approach that helpers, services, tools and other similarly named modules eventually become.

@bigorn0 Thank you for your feedback Ugo, the argumentation does make sense for me as well. We surely plan to continue refactoring that part of the implementation in next iterations. Again, the main intention is to deliver the working functionality that can be tested and verified, not delaying the release with an infinite rounds of reengineering it 👍🏻

Good, then I'm eager to see iteration 2 :)

@bigorn0 Could you please check what's happening with the actions config? Seems like something misconfigured:

Run PR tests (Plugins) (Plugins)